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Abstract 

Stack allocation and first-class functions don't naturally mix to- 
gether. In this paper we show that a type and effect system can be 
the detergent that helps these features form a nice emulsion. Our in- 
terest in this problem comes from our work on the Chapel language, 
but this problem is also relevant to lambda expressions in C++ and 
blocks in Objective C. The difficulty in mixing first-class functions 
and stack allocation is a tension between safety, efficiency, and sim- 
plicity. To preserve safety, one must worry about functions outliv- 
ing the variables they reference: the classic upward funarg prob- 
lem. There are systems which regain safety but lose programmer- 
predictable efficiency, and ones that provide both safety and effi- 
ciency, but give up simplicity by exposing regions to the program- 
mer. In this paper we present a simple design that combines a type 
and effect system, for safety, with function-local storage, for con- 
trol over efficiency. 



1. Introduction 

This paper describes a design for integrating first-class functions 
into languages with stack allocation in a way that does not com- 
promise type safety or performance and that strives for simplicity. 
This d esign is intended for use in the Chapel programming lan- 
guage I Chamber lain et al]|201 111 , but could also provide a sa fer al- 
ternative to the new lambda expressions of C++ | ISO 201 1] and a 
more efficient alternative to the blocks of Objective C I Apple Inc. I 
[201 ltl . The design is meant for performance-oriented languages in 
which the run-time overhead for each language construct should be 
relatively small and predictable. 

The straightforward integration of first-class functions into a 
language with stack allocation poses t ype safety p roblems because 
of the classic upward funarg problem [Moses 1970], illustrated in 
Figure Q] in the Chapel language. The compose function returns 
an anonymous function which refers to parameters f and g of the 
surrounding compose function. Both f and g are functions of type 
f unc (int , int) ; the first int is the input type and the second 
int is the return type. The example then defines the function inc 
and invokes compose to obtain inc2, a function that increments 
its argument twice. Because Chapel allocates parameters and local 
variables on the call stack, the variables f and g are no longer live 
when inc2 is called; the call to compose has completed. During 
the call to inc2, the locations previously allocated to f and g may 



[Copyright notice will appear here once 'preprint' option is removed.] 



proc compose (f: f unc ( int , int ) , 

g: f unc ( int , int ) ) : func (int , int) { 
return fun(x:int){ var y=f(x); return g(y) ; }; 

} 

proc inc(x: int): int { return x + 1; } 
var inc2 = compose (inc, inc); 
inc2(0) ; 

Figure 1. Example of an upward funarg in Chapel. 



contain values of types that are different from func (int , int) , so 
we have a counterexample to type safety. 

To avoid the upward funarg problem, most languages with 
first-class functions do not allocate parameters or local variables 
on the stack; they allocate them on the heap and use garbage 
collection to reclaim the memory. However, designing garbage 
collection algorithms that provide predictable performance is an 
on-goi ng research challenge whereas stack allocation is reliably 
fast iMiller and R ozas 1994]. Advanced compilers for functional 
languages employ static analyses t o determine which variables may 
be safely allocated on the s t ack [Steele 1978, Goldb erg and Parkl 
U990LlTofte and Talpirll994llSerrano and Feelevll 199611 . which im- 
proves efficiency for many progra ms, but still doe s not deliver 
programmer predictable efficiency iTofte et alj2004ll . 

For the Chapel programming language, we seek a language de- 
sign in which upward funargs are caught statically, thereby achiev- 
ing type safety, but that enables higher-order programming and 
gives the programmer control over run-time costs. 

While such a design is not present in the literature, the key 
ingredients are. Tofte and Talpirj I1994L 1 1997fl designed a typed 
intermediate language, which we refer to as the Region Calcu- 
lus, with an explicit region abstraction: values are allocated into 
regions and regions are allocated/deallocated in a LIFO fash- 
ion. The Region Calculus uses a type and effect system a la 
Talpin and Jouvelot 1 1992] to guarantee the absence of memory 
errors, such as the dangling references that occur within upward 
funargs. Late r work relaxed the LIFO restriction on allocation and 
deallocation lAiken et al ] 11991 ICrarv et alJll999L iHenglein et alJ 
l200lll . lTofte et alj I2004H suggest that a programming language (as 
opposed to an intermediate language) with explicit regions would 
provide both pr e dictab le efficiency and type safety. The work by 
iGrossman et alj 1200211 on Cyclone provides evidence that this is 
the case. 

While the type and effect systems of ITofte et alj 1200411 and 
IGrossman et al.1 [2002] support many higher-order programming 
idioms, they still disallow many useful cases that involve curried 
functions, suc h as the ab ove compose function. The lam bda expres- 
sions of C++ |ISQ|2011|1 and the blocks of Objective C lApple Incl 
201 1] offer a simple solution: enable the copying of values into ex- 
tra storage associated with a function. For example, in the compose 
function, the programmer could elect to copy the values of f and 
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g into storage associated with the anonymous function, thereby 
keeping them alive for the lifetime of the function. One might be 
tempted to make this copying behavior th e only semantics , but in 
many situations the copy is too expensive iJarvi e t al. 2007]. (Sup- 
pose the copied object is an array.) In the C++ design, the program- 
mer may choose to either make the copy, incurring run-time cost 
in exchange for safety, or capture the reference, incurring no extra 
run-time cost but exposing themselves to the potential for dangling 
references. 

We take away the following points from this prior research: 

1. The Region Calculus demonstrates that a type and effect sys- 
tem can support many higher-order programming idioms while 
disallowing upward funargs. 

2. Cyclone shows that only a small amount of annotations are 
needed to support a type and effect system. 

3. The C++ and Objective C approach of providing function-local 
storage enables the full spectrum of higher-order programming 
while keeping the programmer in control of run-time costs. 

In this paper we present a language design that uses a type 
and effect system to detect and disallow upward funargs with dan- 
gling references and that also offers the ability to copy values into 
function-local storage. However, unlike the Region Calculus and 
Cyclone, we do not expose the region abstraction to the program- 
mer; doing so would unnecessarily complicate the language from 
the programmer's viewpoint. In our system, the effect of an ex- 
pression is a set of variables instead of a set of region names. The 
variables in the effect are those that may be read by the expression. 

For readers unfamiliar with regions, we present a static and 
dynamic semantics directly for our system and a syntactic proof of 
type safety (Section[3}. The goal of this section is to provide both an 
aid to implementation and a direct understanding of why our type 
and eff ect system en sures type safety, and therefore also memory 
safety iPiercd 120021. As an added benefit, the direct semantics 
supports efficient tail calls through a simple restriction in the type 
system that enables early deallocation. For readers familiar with 
regions, we present a type-preserving translation from well-typed 
terms of our system into the Region Calculus (Section[3]l. 

This paper makes the following contributions: 

1. We make an explicit connection between type and effect sys- 
tems and the upward funarg problem so that implementers 
adding first-class functions to stack-based languages, such as 
C++, Objective-C, and Chapel, can leverage the wealth of prior 
work on effects. 

2. We present a design that balances simplicity (for the program- 
mer and the implementer) with safety and performance. We for- 
malize the design in the definition of a calculus named Feath- 
erweight Functional Chapel (F 2 C). An interpreter and type 
checker for F C are at the URL in the supplemental material. 

3. We give a direct proof of type safety for F 2 C, show that F 2 C is 
parametric with respect to effects by constructing an erasure- 
based semantics, and we relate F C to the Region Calculus 
through a type-preserving translation. 

Section [6] places our contributions in the context of the prior re- 
search in this area and Section|7]concludes the paper. 

2. Overview of the Design 

We start with an overview of our design. To communicate the 
design as clearly and succinctly as possible, we present a small 
higher-order, stack-based calculus, named F 2 C. The calculus has 
explicit type and effect annotations. We point readers interested 
in removing the annotations to the techniques developed for Cy- 
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Figure 2. The syntax of F 2 C. 

clone [Grossman et al. 2002]. We first describe the syntax for F 2 C, 
defined in Figure[2] and then present the important design decisions 
through a series of examples. 

The syntax of F 2 C is separated into expressions and statements 
to streamline the dynamic semantics Q This syntax can be viewed 
as a variant of A-normal form and t here are standard tech niques for 
translating programs into this form I Flana gan et aljl993fl . 

Expressions do not contain function calls or anything else that 
can change the stack. The expressions do include many standard 
things such as variables, integer literals, and primitive operator ap- 
plication. We sometimes use infix notation for operator application. 
For example, x + z should be read as +(x,z). More importantly, 
F 2 C has a function creation expression: 

fun(2::T) [>] {s} 

The x is the function's parameter, of type T. In examples, we 
sometimes take the liberty of using functions with more than one 
parameter. The effect annotation ip declares the set of variables 
from surrounding scopes that may be referred to in the body s of 
the function. The type of the above function is f unc (T, T', \_tp] ) 
where T' is the return type of the statement s. The effect ip in the 
function's type is used to make sure that the function is only called 
when all the variables in ip are live. 

There is also a let expression that is completely standard but 
plays an important role in modeling function-local storage, to be 
discussed shortly. The fix expression is also standard, and enables 
writing recursive functions. We include fix in F 2 C primarily to 
make sure our design does not accidently rely on the assumption 
that all expressions terminate. We postpone discussing the remain- 
ing two forms of expressions. 

The statements of F 2 C are also defined in Figure [2] We syn- 
tactically enforce that every control-flow path ends with a re- 
turn statement to avoid obscuring the type system with the stan- 
dard inachiriery_J[OTpreyenting functions from falling off the 
end I Gross man et all2 0021. The variable initialization statement 

var x=e ; s 

allocates a new location on the stack with the result of e, binding 
the address to the variable x, then executes statement s with x in 
scope. The return statement is standard. 

Statements include two forms of function call. The function call 

var x=e\ ie-i) ; s 

invokes the function resulting from ei with the argument resulting 
from e2- The return value is placed on the stack and its address is 
bound to x, which can then be used in the subsequently executed 
statement s. The effect in the function type of ei must only contain 



' For the monadically inclined reader, the split almost puts F 2 C into 
monadic style with the statements in a mo nad for the call stack. Fo r more 
on monadic regions, we refer the reader to Fluet and Morrisett 1 2006] . 
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1 var x = 1 ; 

2 var addx = fun(z: int)[x]{ return x + z; }; 

3 var twice = fun(f: func (int , int , [x] ) , y: int) [x] { 

4 var t = f (y) ; return f (t) ; 

5 }; 

6 var b = twice (addx, 3); 

7 return b; 



Figure 3. Example with first-class functions and stack allocation. 

variables that are live in the current scope. The tail call 
return ei (e2) ; 

is a function call in which nothing else is left to be done in the 
current function after the call ei (e2) returns. 

Allow Downward Funargs Several variations on the example 
in Figure [3] serve to demonstrate the interplay between first-class 
functions, stack allocation, and effect annotations. The example 
defines a twice function, with a function parameter f that it calls 
twice, first on the parameter y and then on the result of the first 
call. The example also defines the addx function, which adds its 
parameter z and the global variable x. The example then invokes the 
twice function with addx as a parameter; so the addx argument is 
an example of a downward funarg. 

Downward funargs are benign with respect to memory safety 
and are allowed by our type system. In this case, the addx function 
reads from x, so x is recorded in the type of addx. The call to twice 
with addx is allowed by the type system because the type of addx, 
including its effect, matches the type of parameter f . The call to f 
inside twice is allowed because twice has also declared x as its 
effect. Then looking back to the call to twice, it is allowed because 
the lifetime of variable x encompasses the call to twice. 

However, the above twice function is surprisingly specific. It 
may only be called with a function that reads from x. We discuss 
shortly how to make twice more general. 

Disallow Upward Funargs Next consider the twice function 
written in curried form, that is, taking one argument at a time as 
shown below. The function created on line 4 is an example of an 
upward funarg that is disallowed by our type system. It reads from 
three variables, one that is local to the function (y) and two from 
surrounding scopes (directly from f and indirectly from x). The 
return of this function is disallowed because the variable f is going 
out of scope, so this upward funarg contains a dangling reference. 



3 var twice = fun(f: func (int , int , [x] ) ) { 

4 return fun(y : int) [f ,x] {. 

5 var t = f (y) ; return f (t) ; 

6 }; /* Error */ 

7 }; 



Function-local Storage In F 2 C, the programmer can solve the 
upward funarg problem by copying f into function-local storage. 
This can be accomplished with a let expression, which copies (via 
substitution) the result of its right-hand-side into its body. With this 
change, the function no longer reads from f when it is called (the 
read occurs in the let, during the execution of twice), so the type 
system allows the return of this upward funarg from twice. 



3 var twice = fun(f: func (int , int , [x] ) ) { 

4 return (let g=f 

5 in fun(y : int) [x] { 

6 var t = g(y) ; return g(t) ; 

7 }); 

8 }; 



To see how this works, consider the following step of execution, 
where addx = fun (z : int) [x] {return x + z ; }. 

let g=addx inf un(y : int) [x~\ {var t=g(y) ; return g(t) ; } 

— > f un(y : int) [a;] {var t=addx(y) ; return addx (t) ; } 

The let expression has caused the addx function to be copied into 
the body of the function. 

Of course, a production quality compiler would not use substi- 
tution (which implies run-time code generation) but instead would 
use a closure representation of functions. A closure consists of a 
function pointer paired with an array of the values from the let- 
bound and f ix-bound variables that occur free in the function body. 
For readers familiar with C++, a closure is just a "function object" 
or "functor" in which data members are used to store copies of the 
variables. 

To reduce the notational overhead of adding let expressions, 
one can add syntactic sugar to functio n expressio ns for declaring 
that a variable be copied, as in C++ (ISO 201 1], The following 
shows f listed after the normal parameters of the function on line 4 
to indicate that f is to be copied into function-local storage. 

3 var twice = fun(f: func(int,int, [x] )) { 

4 return fun (y: int; f ) [x] { 

5 var t = f (y) ; return f (t) ; 

6 }; 

7 }; 

Effect Polymorphism As described so far, the type and effect 
system is too restrictive because function types are annotated with 
specific variables. For example, the below twice function has a 
function parameter f that is annotated with the effect [x] . Thus, 
calling twice with addx is fine but calling twice with addy is not 
because the effect of addy is to read y, not x. 

var x = 1 ; 
var y = 2; 

var twice = fun(f: func(int,int, [x] ) , y: int)[x]{ 
var t = f (y) ; return f (t) ; 

}; 

var addx = fun(z : int) [x] { return x + z; }; 

var addy = fun(z : int) [y] { return y + z; }; 

var b = twice (addx, 3); /* OK */ 

var c = twice (addy, 3); /* Error */ 

return b + c ; 

The solution to this proble m is to parameter i ze functions with 
respect to their effects iTofte and Tabid 1 19941 IPiercd l2004l ■ In 
F 2 C, the support for this comes from the effect abstraction <x> /, 
which parameterizes its body / with respect to the variable x, and 
effect application e<y>, in which the result of e, an effect abstrac- 
tion, is instantiated by substituting y for x. As an abbreviation, we 
write <z> f for <zi> ■ ■ ■ <z n > f and e<x> for e<xi> ■ ■ ■ <x n >. 

To see this solution in action, we return to the previous example. 
This time we parameterize twice with respect to p, a place holder 
for a variable. The later uses of twice instantiate p with x and y 
respectively to get two different versions of twice that work with 
addx and addy. 

var twice = 

<p> fun(f: func (int , int , [p] ) , y: int) [p] { 
var t = f (y) ; return f (t) ; 

>; 

var b = twice<x>(addx, 3); 
var c = twice<y>(addy , 3); 
return b + c ; 
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Of course, we would like to parameterize with respect to ar- 
bitrary numbers of variables, so that twice could be used with 
fun ctions with no effect or an effect with greater than one variable. 
See iGrossman et all l2002ll for the generalization of effect poly- 
morphism that addresses this need. From a syntactic standpoint, 
explicit effect applicat ion, as in twice<x>, is rather heavyweight. 
iGrossmarTe t al. [2002] also describe how to infer effect applica- 
tion, so we do not discuss this further here. 

A programming language based on our design would provide 
syntactic sugar for the definition of named, effect-polymorphic, 
recursive functions. In this paper, we use the shorthand 

proc <z> fix-.Tn y):T 2 lep] { si } 
to mean 

var / = (let y = y in fix /: <z> func (Ti, T2, [(pi). 

<?> fun(x:Ti) [tp]{ si '}) ; 

S2 

(The portions of the syntax related to z, x, y, and tp are optional.) 

Tail Calls and Effects To support space-efficient tail calls, F 2 C 
pops the current procedure call frame prior to performing the tail 
call. To make this safe, our type system does not allow tail calls to 
functions that read from variables on the current fra me. We depar t 
from the running example to show a classic example I Appei flT992ll . 
listed below, that was problematic for regio n inference. Ideally, this 
example uses 0(n) space; the approach of Tofte and Talpin 1 1994] 
used 0(n 2 ) but the later approach of Aik en et at] Il995tl reduced 
the space to 0(n). Indeed, the below example uses 0(n) in F 2 C 
because the two calls in tail position are executed as tail callsQ 

proc s(i:int): int list { 
if (iszero(i)) { 

return nil ; 
} else { 

var p = dec(i); var sp = s(p); 

return cons(0, sp) ; 

} 

} 

proc f(n:int, x: int list): int [s] { 
var z = length (x) ; 
proc g(; f, n):int [s] { 

var slOO = s(100); return f(dec(n), slOO) ; 

} 

if (iszero(n)) return 0; 
else return g() ; 

} 

var r = f (100, nil) ; 
return r; 

In F 2 C, the programmer knows for sure that every tail call does 
not use extra stack space. Also, the programmer is notified with an 
error message if a tail call could lead to a dangling reference. 

Take Care with Variables Particular care must be taken with 
the implementation of variables in a language with a type and 
effect system such as F 2 C. The straightforward approach leads to 
incorrect conclusions during type checking. Consider the following 
program with two variables with the name x. 

var x = 1 ; 

proc f(a: int): int [x]{ return a + x; } 
proc g(x: int): int [x]{ return f (x) ; } 



2 For the purposes on this example, F 2 C is extended with support for if 
statements and lists in the obvious way. 



var y = g(2) ; 
return y; 

Inside g, the tail call return f (x) has the effect {x}. A naive type 
checking algorithm would reject this tail call because the parameter 
x is popped prior to the call. Of course, that is the wrong x. 

A straightforward solution is for the compiler to rename all the 
variables in the program to ensure each name is used in a variable 
declaration only once. The result of such a renaming is shown 
below for our example. 

var xi = 1 ; 

proc fi(ai: int): int [xi]{ return ai + xi ; } 
proc gi(x2: int): int [xi]{ return fi(x2); } 
var yi = gi(2) ; 
return yi ; 

Now the tail call return f 1 (X2) has the effect xi, which is be- 
nign because X2, an d not xi, is popp ed prior to the call. (Another 
solution is to use the lde Bruiinl Il972ll representation for variables.) 

Summary of the Design The F 2 C calculus combines first-class 
functions with stack allocation, enabling the full range of higher- 
order programming while ensuring type safety and minimizing 
programmer-visible complexity through a regionless type and ef- 
fect system. Further, the design gives the programmer control over 
efficiency by providing by-reference and by-copy options for cap- 
turing the free variables of a function. 

3. Direct Semantics and Type Safety 

This section presents the dynamic and static semantics of F 2 C and 
then a proof of type safety. 

3.1 Dynamic Semantics 

We give a substitution-based, single-step s emantics for F 2 C that 
takes insp iration from the semantics of Hels en and Thiemannl 
12000] and lCrarvetaH I1999H . However, to make stack allocation 
explicit, the semantics operates on states of the form 

(s, k, a, n) 

where s is the body of the currently executing function, k is the 
control stack, a is the value stack, and n is the number of stack 
values that are associated with the currently executing function. On 
a real machine, the control and value stacks are intertwined; our 
formalization is more clear with them separated. We write e for the 
empty stack and v ■ a for pushing v onto the front of the stack a. 
(So we represent stacks as cons-style lists.) We write \a\ for the 
length of stack a and concatenation of stacks is juxtaposition, so 
the concatenation of o\ and 02 is written a 1 a 2 - 

In our semantics, variables are mapped to stack locations (rep- 
resented with natural numbers). We index starting from the back of 
the stack so that existing locations are not disturbed by growing the 
stack at the front. Given the notation cr^ for the normal front-to-back 
indexing, we use the following notation for indexing back-to-front. 

a{i} = cr| cr |_ 1 _ i 

As usual in a substitution-based semantics, the syntax of the 
language must be slightly expanded for use by the dynamic seman- 
tics, which we show in Figure|4]with the differences highlighted in 
gray. The most important difference is that expressions and effects 
include stack locations. Stack locations have the form It, com- 
bining the address i with type T. This type annotation is ignored 
by the dynamic semantics (see Section^; it is merely a technical 
device used in the proof of type safety. The need for these type 
annotations propagates to needing type annotations in variable ini- 
tialization and for function return types. These type annotations are 
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Hi = " 

[op(ei, . . . , e n )]<T = 5(op, ([ei]<T, . . . , [e„]o-)) 
[fun(:r :Ti) :T 2 M {s}l<r = f un(x :Ti ) :T 2 M {s} 
[leta;=ei ine 2 ] CT = [[aj:=[eiI CT ]e 2 ] CT 
[fixx-.T.flv = {[x:=iixx:T.f]fl a 
[<x>/] CT = <x>f 

[e<£ T >] CT = l[x:=e T ]e% if [e] CT = <x>e' 
Figure 5. Evaluation of closed expressions. 



straightforward to insert during the semantic analysis (type check- 
ing) pass of a compiler. One other difference is that we add a top 
type T that is used by the type system to classify effect parameters. 
In Figure [4] we omit most of the statements because they remain 
unchanged with respect to Figure [2] The only change is adding a 
type annotation on the variable initialization form. 

Figure[5]gives the evaluation of closed expressions (expressions 
with no free variables) to values. Evaluation is parameterized on 
the value stack a so that stack locations It can be evaluated to 
their associated value. Most of the equations in this definition 
are standard, such a s the 5 functio n that gives meaning to all the 
primitive operators [Plotkin 1975]. The evaluation of an effect 
application e<lr> first evaluates e to an effect abstraction <x>e', 
substitutes It for x in e', and evaluates the result. 

The single-step reduction relation over states is defined in Fig- 
ure^ A variable initialization statement var x:T=e; s evaluates e 
and pushes it on the value stack then substitutes its stack location 
for x in s. A function call var £=ei(e 2 ) ; si evaluates e\ to a 
function value f un(t/ : Ti) : T 2 Lip] {x}, evaluates e 2 and pushes it 
on the value stack, substitutes its stack location for y in s, then 
pushes the current call frame onto the control stack. A tail call 
return ei(e 2 ) ; is similar except that it pops n values from the 
stack. (The drop function returns a list that lacks the first n ele- 
ments of the input list.) The statement return e ; evaluates e, pops 
n values from the stack, pushes the value of e on the stack, and re- 
instates the top frame from the control stack, substituting the stack 
location of e for x in s. 



Definition 1. The dynamic semantics ofF C is specified by the 
partial function eval defined by the following. 

eval(s) — observe(\e\ a ) iff(s, e, e, 0) — > (return e;,e, a, n) 

where observe is defined on values as follows: 

observe(n) = n 

observe(fun(x :T\) :T 2 [tp]{s}) = fun 

observe(<x>e) = abs 

3.2 Static Semantics 

As discussed in Section|2] we require that all variables be uniquely 
named in a pre-processing pass of a compiler. 

The type system for F 2 C is inductively defined in Figure [7] 
The judgment for well-typed expressions has the form V; ipi h 
e : T while the judgment for well-typed statements has the form 
F; (pi; ip2 \~ s : T. The V is a type environment (symbol table), 
mapping variables to types, and is described in more detail below. 
The effect (pi specifies which variables may be read from; the 
second effect </p 2 in the context for statements keeps track of which 
variables are popped from the value stack upon a return from 
the current call frame, that is, it keeps track of the parameters 
and local variables. We discuss the important aspects of the type 
system in the following paragraphs after introducing our slightly 
non-standard type environments. 

Type Environments We write for the empty type environment 
and r, x:T for extending the type environment V with the binding 
of a stack-allocated variable x to type T. We write V, s:copy T for 
extending the type environment with variables that are bound by 
the let or fix expressions. The copy annotation helps the type 
system distinguish between reads from stack-allocated variables, 
which count as an effect, and reads from let-bound or fix-bound 
variables, which do not. Looking up a variable y in an environment 
r, written r(j/), is defined as follows. 



(V,x:T)(y) = 



T 

r(y) 



if x = y 
otherwise 



(r,a::copyr)(y) 



copy T if x = y 
T(y) otherwise 



Well-typed Expressions An occurrence of a stack-allocated vari- 
able must both be in scope and in the declared effect of the sur- 
rounding function. In contrast, a let-bound or fix-bound variable 
need only be in scope. During execution, stack locations are sub- 
stituted for stack-allocated variables. A stack location is well typed 
if it is in the declared effect. This rule is simple but subtle. A well- 
typed program in mid execution may have functions that contain 
dangling stack locations. The type system ensures that such func- 
tions are never called. Thus, the typing rule for stack locations does 
not look at the actual value stack, but instead merely checks that the 
stack location is in the declared effect of the surrounding function. 

A function expression is well-typed if its body is well typed in 
the declared effect (p2 enlarged with parameter x. The second effect 
context is {x} because x is popped from the stack upon return from 
this function. The typing rules for the rest of the expressions are 
standard. 

Well-typed Statements The typing rule for variable initialization 
is straightforward, given that it allocates the variable on the stack. 
The role of the effect annotations in function types can be seen in 
the typing rules for function call and tail call. In both cases, the 
effect of the function ip-j, must be contained in the current effect <pi. 
In addition, for tail calls, ip 3 must not overlap with <^ 2 , the local 
variables of the current function. 
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((var:r:T=e; s),K,a,n) — 




=\cr\ T ]s,K, \e\ a • 


a,n + i) 




(INIT) 


((var i=ei(e 2 ); Si),K,a,n) — 


-+(br- 


=\<r\ Tl ]s2, (x:T 2 , 


s 1 ,n) ■ k, [e 2 ] CT 


■a,l) 


if |ei] CT = fwa.(y:T 1 ):T 2 [(pl{s 2 } 

(Call) 


(return e\ (e 2 ) ; , ft, a, n) — 




=(\a\-n) Tl ]s, k, 


[e 2 ] CT ■ drop(n, 


*),!> 


if [ei] CT = fun(j/:Ti):T 2 [<?]{«} 

(TailCall) 


(return e ; , (x:T, s, 712) • k, a, m) — 




=( \a — ni)r]s, k 


[ej a ■ drop(ni 


cr),n2 + 1) 


(Return) 



Figure 6. The single-step reduction relation. 



The rules for tail call and return must both prevent the escape 
of upward funargs with dangling references. The rules accomplish 
this by requiring that the free variables in the returned value's type 
not include any local variables. The free variables of a type, written 
fv(T), is defined as follows. 



fv(int) 

fv(func(Ti,T 2 , [p])) 
fv(<x>T) 



fv(Ti) U tp U fV(T 2 ) 
fv(T) - {x} 



3.3 Substitution vs. Environments 

We originally formulated the dynamic semantics of F 2 C using 
environments instead of substitution. The authors prefer environ- 
ments because they bring the semantics a step closer to a real im- 
plementation and because they more closely correspond to a pro- 
grammer's view of variables. However, the definition of well-typed 
states became much more complex because it was difficult to define 
a notion of well-typed environment that interacted properly with 
effect polymorphism. Switching to a substitution-based semantics 
removed the need for well-typed environments, which simplified 
the definition of well-typed states and the proof of type safety. 

3.4 Type Safety 

Type safety for F 2 C means that a well- typed program cannot get 
stuck and that the result of the program matches its static type. 
The notion of stuck models untrapped errors such as memory er- 
rors [Cardelli 1997]. Technically, getting stuck means getting into 
a state that neither has a subsequent state (as defined by the step 
relation — >) nor is a final state, as defined below. 

Definition 2 (Final State), final (?) if and only if the state ? is of the 
form ( re turn e ; , e, a, n). Given a final state ?, we write result(c;) 
for observe(\e\ a ). 

The formal statement of type safety unravels the negative "not 
stuck" to arrive at the following positive form. The definition of 
a well-typed observation (for h result (?) : T below) is given in 
Figure [8] 

Theorem 1 (Type Safety). 7/0; h s : T and (s, e, e, 0) — >* 
then either finalic,') and\- result (?) : T or <, — > for some ?' '. 

In the following, we give a proof for the Type Safety The- 
orem, including the statement but not the proofs of the major 
lemmas. (This proof i s rela ted to the proof of type safety by 
iHelsen and Thiemann! |2000] for the region calculus in that we 
take the syntactic approach and have a substitution-based seman- 
tics.) The proofs of the lemmas are in the accompanying technical 
report. (See the supplemental material.) 

As usual, the proof of type safety proceeds by induction on the 
reduction sequence (s, e, e, 0) — >* ?. The induction step of the 
proof concerns a single reduction, from some intermediate state ?i 
to the next state qj. What needs to be proved for such intermediate 



r h ip 



r h t 



r 1- ip if(\/x e p. 3t.v(x) = t 



r h Ti r h t 2 

T\-cp 



r,s:T h T 



rhT rhint r hfunc(Ti,T 2 , rh<i>r 



F;ip\- e:T 



T(x) = T xE<p r(x) = copyr 



IT £ <P 



T;iphx:T T;iphx:T T;ip\-l T .T 

ty P eof(op)=(Ti,...,T n ,T r ) 
r^he, : Tj fori E{1,..., n} 

T; ip h n : int T;<p \- op(ei, . . . ,e n ) : T r 

T h func(ri,T 2 , Dgglj T,x:T 1 -p 2 yj{x}\{x} h s : T 2 
r ; <^i h fun(a;:Ti) :T 2 [^2]{s} : func(Ti,T 2 , [<p 2 l) 

F; tp \- ei : Ti 
r,x:copyTi;<p h e 2 : T 2 F, x:copy T; p h / : T 

F; tp h let x=e\ in e 2 : T 2 T; p \- fix x:T. f : T 

r, a; : T; h e : T F;ph e: <x>T 

T-p h <x>e : <x>T T;p\- e<l> : [x:=l]T 



T; ip; p h s : T 



T\p\\-e:Ti 
r, x:Ti; ipi U {x}; ^U{i}hs: T 2 

V; pi;p 2 \~ var x:T\=e\ s : T 2 

Y;p\ h ei : f unc (Ti,T 2 , [^3] ) r; pi h e 2 : T\ 
T,x:T 2 ;<p 1 U{x};<p 2 U{x}\- s : T 3 p> 3 Q <Pi 
T; pi;p 2 I - var a;=ei (e 2 ) ; s : T3 

T;p 1 \-e 1 : f unc (Ti, T 2) [^3] ) r; pi h e 2 : Ti 

If 3 C J)l - <^2 fV(T 2 ) n 1/32 = 

T;tp\;ip 2 h return ei(e 2 ); : T 2 

r ; ¥3i h e : T fv(T) n ^2 = 
r; y5i ; p 2 h return e ; : T 

Figure 7. The typing rules for expressions and statements. 
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KTj 

h r r h r 

h a : S 

0;0 h u : T h cr : E 
hf : t h b-(T : T'E 



Shy 




E h k : T => T 



E h ip i drop(n, E) h tpi — tpi 
$,x:Ti;<pi U {x};ip 2 U{i}hs:T 2 
h Ti drop(n, E) h k : T 2 ^ T 3 
Ehe:T^r E h (x:Ti,s,ra) • « : 2\ => T 3 



h 


C : T 








E h 




p(n, E) h y>i — ip 2 ®; (pi; (f2 \~ s : Ti 






h ct : E 


drop(n, E) h k : Ti =^ T 2 








h (s, At, <r, n) : T2 


h 


o : T 







h n : int h fun : func (Ti, T 2 , [] ) h abs : <x> T 



Figure 8. The typing rules for states and observations. 

states is that a well-typed state must either be a final state or it can 
take a step to another well- typed state (progress and preservation). 

Lemma 1 (Step Safety). If h ci : T, then either final or 
<Ti — > £2 and h ?2 : T/or .some <&• 

The Step Safety proof hinges on the definition of well-typed states. 

Well-typed States The definition of a well-typed state is given in 
Figure[8] Getting this definition right, such that we can prove Step 
Safety, is the main challenge in the overall proof of Type Safety. 
The definition of well-typed states relies on several au xiliary judg- 
ments whi ch roug hly correspond to the ones used by ICrarv et alJ 
1 1999] and lSabrvl 1200211 . The judgment h a : E is for well-typed 
value stacks, where E is a list of types. The judgment Shy says 
that E satisfies tp, which is to say, any value stack of type E can 
be used to safely execute a statement that requires effect tp. The 
judgment E h k : Ti => T2 is for well-typed control stacks. The 
control stack k is expecting a value of type T\ (returned from the 
current call frame) and ultimately produces a value of type T2, so 
long as the value stack has type E. 

The rule for a well-typed state (s, k, cr, n) requires that the 
statement s be well-typed in the context of an effect declaration 
tpi and local variables if 2- The value stack must be well typed 
(h a : E) and, critically, its type E must satisfy the effect tpi which 
is needed to safely execute statement s. Further, popping n items 
from E must yield a stack typing that satisfies tpi — (pi, that is, the 
current live variables but not including the n local variables to be 
popped. The typing rule for extending the control stack with a call 
frame is analogous to the typing rule for states, the only difference 
being that a call frame is expecting a return value of type Ti that it 
binds to the stack-allocated variable x. 

3.4.1 Expression Evaluation Safety 

All of the reduction rules (Figure |6) require evaluating an expres- 
sion, which means we need a notion of type safety for expressions. 
This is captured in the Evaluation Safety Lemma, stated below. We 



only deal with closed expression (r = 0) because, in a well-typed 
program, the variables are substituted away before we come to eval- 
uate an expression. The process of evaluation replaces stack loca- 
tions with their associated values, so the resulting value is well- 
typed in an empty effect context. There may, however, still be ef- 
fects in the type T (if the value is a function and the body of the 
function contains stack locations). The effects in T dictate how the 
resulting value can be used. To ensure that the stack locations cor- 
respond to values of the appropriate type, this lemma includes the 
premises h a : E and E h tp. 

Lemma 2 (Evaluation Safety). //0 h tp, 0; ip h e : T, h a : E, 
and E h tp, then 0; h [e] CT : T. 

Looking at the various cases for evaluation in Figure [5] there 
are several that require knowing that a subexpression evaluates 
to a particular form of value. For example, to evaluate an effect 
application e<lT>, the expression e must evaluate to an effect 
application, which has the form <x> e' . We repeat this evaluation 
rule below. 

[e<^T>]]] CT = l[x:=£ T ]e% if |e] CT = <x> e' 

From the typing rule for e<£r>, we see that e has type <x>T' 
for some T', and by the induction hypothesis, the value JeJ CT also 
has type <x> T'. The Canonical Forms Lemma, stated below, tells 
us that the value JeJ CT must therefore be an effect abstraction (and 
similar facts about the other types). 

Lemma 3 (Canonical Forms). // 7 0; h v : T, then exactly one of 
the following holds. 

1. T — int and v = n for some n, or 

2. T = func(T±,T2, [<p]) and v = fun(x :Ti) :T2 [<p]{s} for 
some x,T\,T%ip,s, or 

3. T — <x>T' and v = <x>efor some x and e. 

The evaluation rules for let and fix involve substituting a 
(closed) expression for a variable. Thus, we need to know that sub- 
stitution, given well-typed expressions, produces a well-typed ex- 
pression. Because expressions contain statements, and vice versa, 
this Lemma must be proved simultaneously for expressions and 
statements. 

Lemma 4 (Substitution Preserves Types). 
Suppose that 0; h e : Ti and h Fi, £:Ti, T2. 

1. #Ti,a;:Ti,r2;</Ji h ei : T 2 , then Ti , T 2 ; h [a;:=e]ei : Ti. 

2. IfTi,x:Ti,Ti; tpv,tpi V- s : T% 
then Y\, Y2; tpv, f2 h [x:=e]s : Ti. 

Such a substitution lemma often takes a different form, with no 
T2, and instead relies on a Permutation Lemma to keep the bind- 
ing for x on the right-most end of the type environment while going 
under a function expression. However, we can not permute environ- 
ments in F 2 C because variables may appear in types, so the partic- 
ular sequencing of variables in the environment is rather important. 
(For similar reasons, permutation does not hold in polymorphic cal- 
culi such as System F.) The expression e being substituted-in may 
be spliced into a context with a different typing environment with 
possibly many variables in scope. This is irrelevant to the typing of 
e because e does not have any free variables. The following Envi- 
ronment Weakening Lemma makes this precise. 

Lemma 5 (Environment Weakening). 

Suppose h r, h ipi, and h tpi. 

1. If 9; <pi V- e : T, then Y; </?i h e : T. 

2. If '0; ipi ; ip>2 V~ s : T, then Y; ipi; tpi h s : T. 

The expression e being substituted also goes from a context 
with no effects to a context with possibly many effects. Thus, we 
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also need weakening for effects. The following Effect Weakening 
Lemma does not need to be proved simultaneously for statements 
because the typing of the body of a function does not depend on the 
current effect. 

Lemma 6 (Effect Weakening). IfT;tp\-e:T,(p<Z<p', and 
T h ip', then T;ip' h e:T, 

The evaluation rule for effect application involves substituting 
a stack location for a variable. Substituting stack locations is more 
involved than substituting expressions because stack locations oc- 
cur in effects and therefore in types. The proof that substitution 
of stack locations preserves types requires simultaneously proving 
this property for types, expressions, and statements. 

Lemma 7 (Substitution of Stack Locations Preserves Types). 
Let [X] stand for \x~iTx\X in the following. 
Suppose Ti, x:Ti, T 2 \~ (pi and Ti, x:Ti, F 2 h ip 2 . 

1. IfT^x-.T^Tz V- T 2 , then T 1; [T 2 ] h [T 2 ]. 

2. //ri,x:ri,r 2 ; ^ihe: T 2 , then Ti, [r 2 ]; [ipi] h [e] : [T 2 ]. 

3. IfT\,x:Ti,T<i; tpi; <p% h s : T 2 , 
then ri,[r 2 ];[^i];[^ 2 ] h [s] : [T 2 ]. 

Of course, to handle the case of evaluating a primitive operator, 
we require that all the primitive operators be type safe. 

Constraint 1 (Type safe primitive operators). If typeof (op) = 
(Ti, . . . , T n ,T r ) and 0; h v r : T % for i £ {1, . . . , n), then 
8(op, (vi, ...,«„)) = v' and 0; h v : T r for some v . 

No other lemmas are required to prove Evaluation Safety. 
3.4.2 Step Safety 

The proof of Step Safety requires a few more key lemmas. Lemma[8] 
is a consequence of how the type system is designed to prevent 
upward funargs, that is, the return of functions with dangling refer- 
ences to local variables. 

Lemma 8 (Locals not in Return Type). Suppose F h tp\ and 
T h ip 2 . IfT; tpi; tp 2 h s : T, then fv(T) n <^ 2 = 0. 

The substitution of stack addresses into the return type of a function 
doesn't change the return type (which would break type preserva- 
tion), because of the above lemma together with the following. 

Lemma 9 (Substitution of Non-free Variables). Ifx £ fv(T), then 
[x:=£ T ,]T = T. 

A function may have fewer effects than are present in the calling 
context, so we need the following weakening lemma. 

Lemma 10 (Satisfaction Weakening). //S h (fi and ip 2 C <p lt 
then E h ip 2 . 

Finally, in tail calls and when returning from a function, we pop 
the values corresponding to parameters and local variables from 
the stack, but the remaining stack is still well typed. 

Lemma 11 (Drop Stack), // h <r : E, then h drop(n,o) : 
drop(n, E). 

The proof of Step Safety (LemmaQJ then proceeds by case analysis 
on the statement component of the state ?i . 

4. Erasure-based Semantics 

An important question from both the semantic and implementa- 
tion perspective is whether the execution of an effect abstraction 
depends in any way on the effects with which it is instantiated. We 
answer this question in the negative by demonstrating that F 2 C can 
be implemented using an erasure-based approach. A more direct ar- 
gument for this property, known as relational parametricity, can be 



[a; J — x 

[nj — n 

[op(ei . . . e„)J = op([eiJ ... [e n \) 

[let x=e\ ine 2 J = let a;=[eij in [e 2 \ 

[±ixx:T.f\ = fix x. [f] 

[e<l>\ = [e\ 

[f un (as : T):T [93] {s}J = fun(a:){LsJ} 

L<*>/J = L/J 

[_var x:T=e; s\ — vara;=LeJ; [ S J 

[var x=ei (e 2 ) ; sj = var £=[eij ( |_e 2 J ) ; [s\ 

[return ei(e 2 ) ; J = return [ei J ([e 2 \ ) ; 

[return e ; J = return [ej ; 



Figure 9. Erasure function 

accomplished via a proof based on logical relations, but we leave 
that for future work. 

Concretely, because effect abstractions do not depend on their 
arguments, it is unnecessary to perform effect substitutions at run- 
time. In the direct semantics of F 2 C, evaluation of effect applica- 
tions e<lr> involves substitution of the stack location It into the 
subterms of e. However, since effect abstraction variables may be 
substituted by concrete variables of any type, effect variables may 
only be used in effect applications and function effect annotations, 
which do not interact with the rest of the program at runtime — 
in other words, F 2 C programs are parametric with regard to effect 
polymorphism. 

We remove both the type and effect annotations by an erasure 
function, defined in Figure|9] We even erase effect abstractions and 
effect applications. The syntactic restriction in F 2 C that the body 
of an effect abstraction is an abstraction (a value) means that there 
is no need to delay the evaluation of the body (because the body is 
already a value). 

We may evaluate erased programs with similar rules to those 
which evaluate F 2 C and we refer to the resulting evaluation func- 
tion as eval erase d. The similarity of these rules to those for F 2 C 
leads us to the following: 

Proposition 1 (Preservation of semantics under erasure). If$; 0; h 

s : T, then eval(s) = eval eraa ed{[s\). 

We have performed rigorous testing of this property and found 
no violations. It should be straightforward to prove this preserva- 
tion of semantics via a simulation argument. 

5. Translation to the Region Calculus 

In this section we relate F 2 C to a region calculus, i n particular, a 
calculus similar to Henglein's ETL and RTL calculi | Pierce 2004]. 
The goal of this section is not to provide an aid to implementation, 
but to aid the reader in understanding the relation between our 
work and prior work on regions. Thus, we choose a relatively 
prototypical region calculus at the cost of losing efficient tail calls. 
(Ther e are other region-based calculi that w ould enable efficient tail 
calls lAiken et alJl995llCrarv et~aill999H .) 

The syntax for the region calculus is defined in Figure [Tol 
The type system is standard | Pierce 2004]. We use the variable 
r to range over expressions, to easily distinguish region calculus 
expressions from F 2 C expressions. The form new p. r allocates an 
empty region and binds it to the name p for use in r. The form 
r at p allocates a location in region p, evaluates expression r and 
stores its value into that location, then returns the location. The 
form r \ p evaluates r to a location and dereferences the location, 
that is, extracts the value stored at that location of region p. In 
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region variables p 

effects ip 

types T 

expressions r 



{P,---,P} 

int | T 4 T | Vp. T | T at p 
x | n | op(r, . . . , r) 
| A:r. r | r r | f ix x. r 
| new p. r \ r at p \ r ! p 
I Ap.r | r[p] 



Figure 10. A region calculus 



addition to the forms in Figure [TO] we use the following syntactic 
sugar: \etx=r\ inr 2 = (Aa;.r 2 ) ri. 

Figure QT] shows our translation from F 2 C to the region calcu- 
lus. The translation functions take two parameters, the first some 
syntax (expressions, etc.) and the second a partial function from 
variables to regions. The main idea behind the translation is that 
we allocate a new region for each variable that is stack allocated in 
F 2 C. This idea is realized in the translation for initialization state- 
ments shown below. The new p allocates the region for the variable 
x and the expression [e] r at p assigns the value of e into a new 
location in the region. This location is bound to x. The following 
statement s is translated using the mapping R(x:=p), that is, ex- 
tending R with the association of region p to x. 



[var x=e ; s] R = new p. let x= 
where p is fresh 



[ fl at pin M R ( x:=p) 



The second half of the story is the translation of variable occur- 
rences. If R associates a region p with the variable x, then we trans- 
late the variable x to x ! p, which dereferences the location that is 
bound to x. Otherwise, the variable x must have been bound by 
either a let or fix, in which case there is no need to dereference. 



p if R(x) = p 
otherwise 



The translation from F 2 C to this region calculus is type preserv- 
ing, that is, it maps well-typed programs to well-typed programs. 
The proof is in the accompanying technical report. 

Theorem 2 (Translation to Regions Preserves Types). Suppose 
F h R, F h (pi, and T ~jj T r . 

1. IfV; tpi\- e :T, then T r ; [<pij R h [e]jj : [T] fl . 

2. IfV; <p 2 h s : T, then V r ; l^\ R h {s\ R : {T\ R . 



We already proved type safety in Section [341 with respect to the 
direct semantics of F 2 C. With Theorem[2]in hand, we could write 
an alternative proof that relies on the type safety of the region 
calculus. 

The translation to regions is also be semantics preserving. That 
is, evaluating a program s under the direct semantics yields the 
same result as translating the program and t hen evaluatin g under the 
dynamic semantics of the region calculus |Pierce 2004], for which 
we use the name evaln. We have tested this property on numerous 
programs and have found no violations. The proof of this should be 
straightforward using a simulation argument. 



Proposition 2 (Semantics Preserving). If ( 

eval(s) — evalnilsj®). 



h s : T, then 



6. Related Work 

Here we place the design of F 2 C in relation to other points in the 
design space. To the best of our knowledge, F 2 C provides a unique 
balance of safety, efficiency, and simplicity through its combination 



IT}r [int] H = int 

[func(Ti,r 2 , = [Ti]h ^ [T 2 ]h 

i<x>t}r = v p . m R(x:=p) 



Mr 



P> R = 



x I p if R(x) = 
x otherwise 



Mr = n 

[op(ei, . . . , e n )\ R = op([ri]fl, . . . , [r„]it) 
[fun(a;:Ti) :T 2 [<p] {s}\r = Ay. new p. leta;=yatpin ls\ R ( x .- p ) 
where y, p are fresh 
l<x>fU = Ap. I/l« (aB=p) 
where p is fresh 
[let x=ei ine2]fl = let £c=[ei]j? in \e2\R 
[fixx:T. /l« = fiix.[/]« 
\e<x>\ R = le\ R [R{x)] 



Mr 



[var x=e; s} R = new p. let a;=|[ej fl at p in {sj R ( x .- p ) 
where p is fresh 
Jvar x=ei (e 2 ) ; s} R = new p. let x=e in [s]it(a, := p) 

where p is fresh and e = ([eijjj [e2]ij) at p 
[return ei (e 2 ) ;}r = [ei]jj [e 2 ]i? 
[return e-J R — [e|n 



T / T 



(F,s:T) ~r (T r ,y:lTjR,x:{Tj R3L tR(x)) 

t ± t r r r 



(r,a;:T) (F r , x:\T\ R at 7?(x)) 

r ~b v r r ~A r r 



Ma 



r h i? 



(r,x:T) T r (r,a;:copyr) ~r (r r , K:[T] fl ) 

Mh = {R(x) \ x€ip} 
Vs. (3T. r(*) = T) iff (3p. fl(ar) = p) 



Figure 11. Translation of F 2 C to a region calculus. 



of a regionless type and effect system and programmer controlled 
function-local storage. 



Effici ent but un safe The lambda expressions of C++ IISOl l201l1 . 
Jarvi et al. 2007] give programmers control over whether to capture 
references to variables or to make copies. The design of F 2 C 
offers the addition of static checking to catch upward funargs with 
dangling references. 



Safe but less efficient The blocks in Objective C I Ap ple Incl 
1201111 give programmers a choice between copying the value of a 
variable into function-local storage (the default) or storing the vari- 
able on the heap (called _block storage) with automatic memory 
management. Unfortunately, neither of these options is ideal for the 
most common use case for first-class functions: downward funargs. 
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In such situations, storing the variable on the stack and capturing a 
reference to it is both safe and the most efficient. 

Safe but efficiency is less predictable Compilers for garbage- 
collected languages, such as Java, Standard ML, and Scheme, 
optimize memory all ocation by performing static analyses (suc h 
as escape analys is iGoldberg and Parkl 1 19901 . IChoi et ail 11999m , 
regi on inference ITofte and Tarpin| [l 99411 . and storage use analy- 
sis ISerrano and Feelevl 1 1 996TI ) to decide when objects can use a 
FIFO memory management scheme. However, from the program- 
mer standpoint, whether the static analyses succeeds on a given 
program is unpredictable, which in turn means that the time an d 
space efficiency of the program is unpredictable | Tofte et alj2004l . 
The design of F 2 C offers an alternative in which programmers 
can mandate the stack allocation of objects, thereby achieving pre- 
dictable efficiency. 

Safe and efficient, but complex Several programming languages 
employ type and effect systems to provide safety a nd efficiency, but 
at the cost of exposing regi ons to the programmer [ Grossma n et alj 
|2002| . iBovapati et al. 2003]. (Several intermediate representations 
also use explicit regions, but because they are intermediate rep- 
rese ntations, regions are not necissarily expo sed to the program- 
mer ICrarv et alJ l999. Tofte and Talpi nll994Tl .) Instead of regions, 
the F 2 C design relies on traditional stack allocation where param- 
eters and local variables are implicitly allocated on the stack. The 
effects of F 2 C are sets of variables instead of sets of region names. 

7. Conclusion 

This paper presents a design for mixing first-class functions and 
stack allocation that ensures type safety, enables the full range of 
higher-order programming, and gives the programmer control over 
efficiency while minimizing programmer-visible complexity. The 
design uses a type and effect system based on variables instead of 
region names. The system allows downward funargs and disallows 
upward funargs with dangling references. To facilitate safe upward 
funargs, the design gives programmers the choice of copying val- 
ues into function-local storage. The paper formalizes the design in 
the F 2 C calculus, defining its syntax, type system, and dynamic 
semantics, and gives a proof of type safety. This paper also demon- 
strates that F 2 C is parametric with respect to effects so effect ab- 
stractions can be implemented via erasure. Finally, the paper relates 
F 2 C to a region calculus through a type-directed translation. 
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